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Intended User Profiles 

LeonovQWERTY is intended for coding programmers, English text authors (e.g. business, legal, 
literary), and computer users working with digits (e.g. in spreadsheets, scientific calculator, etc.). If you 
decide to test this layout, please ensure that you test it with the wristpads of the specifications that are 
described further below. Please email your feedback from testing and suggestions for the next version to 
maxOleonovq werty.org Updates and news will be disseminated via LeonovQWERTY Facebook Page , so like 
and subscribe if interested in keeping yourself updated. 



Design Philosophy on Layout of Inputs 

LeonovQWERTY (firstly) keeps all the alphabetic keys in a layout that retains the sequences of 
letters on each row of keys according to the original QWERTY layout with some adjustments for the layout 
of mechanical keys in ErgoDox, while (secondly) completely rearranging all other non-alphabetic keys on 
the keyboard. Both of these design decisions are aimed to make a novice user's transition from a typical 
QWERTY keyboard to ErgoDox as comfortable and as quick as possible. 

LeonovQWERTY layout is designed and based on my finding from personal experience - that there 
is no single best palm/wrist position for a keyboard, and it all instead depends on the typing activity, such 
as text composition, spreadsheet inputs, web browsing, etc., that involves a specific key group that is 
frequently hit during that specialized typing activity. So for this reason, in LeonovQWERTY all keys on the 
keyboard are organized (in other words grouped, clustered, gathered) into functional key groups or areas. 
In practice, this translates into the following situation: when key groups are used during prolonged typing 
activity, each hand (R and L) is positioned to be most comfortable to a particular set of keys that are 
frequently used during that typing activity. This minimizes wrist rotation and instead focuses the typing 
activity as much as possible on finger movements, particularly the finger movements between the "open 
palm" and the "closed fist" finger positions. Moreover, it needs to be taken into consideration that since 
the palm is positioned for a different key group differently, correspondingly the thumb key cluster is then 
going to be presented to the user's thumb at a different angle and proximity per each key group. 

I tried to organize the groups into as fewer columns as possible, my target was five columns max 
(unfortunately two exceptions crept in) in order to minimize left-right wrist rotation. Wrist rotation is 
probably unavoidable, yet it can be minimized by being required only for more rarely used inputs during a 
typing activity. It would be ideal if the results of the testing are such that the current LeonovQWERTY 
layout of key groups is found to minimize or even eliminate the left-right rotation of the wrists, and in 
those cases where a key is not reachable from the current wrist position that this layout requires that the 
whole hand is lifted off the wristpad in order to reach a less frequently used key. Traditional one-piece 
keyboards make it very easy for users to turn their wrists left and right all the time - forcing the user to lift 
the hand entirely due to the layout of keys could be a very efficient solution. 

Grouping keys into functional groups also makes it straightforward for the brain to look for a 
particular key, because the brain knows that for example all digits are in the top right-hand corner, cursor- 
related events are normally managed below the right-hand QWERTY, and most common punctuation 
characters for text typing are below the cursor row, and so on. I see this as particularly useful for faster 
adoption by a larger user base, because new users of this layout can quickly locate a key based on the 
functional key group the key logically belongs to. This is something that only a keyboard with an 
unconventional layout of mechanical keys, such as ErgoDox, can offer for experimenting. 

Another major assumption of LeonovQWERTY is that for balanced finger workload when typing by 
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both hands, the number of QWERTY keys on each hand has to count in, on equal weight with the 
alphabetic characters, also Space, Enter, and the most frequent sentence punctuation character keys 
(comma, period, dash, colon, question mark, etc.). So any letter frequency statistics have to have these 
characters on par with the alphabetic characters. 

A word of caution on using the statistics of frequency of key usage in placing keys - different uses 
of the keyboard result in different frequencies of use of various keys, therefore making it undesirable to 
arrive at a set of common statistical averages that could have been used for one common frequency- 
based layout. There have to be trade offs in the positioning of some keys, so key placement becomes 
more of an art with various preferences. That said, in LeonovQWERTY, retention of preferably one area for 
a key group is prioritized. Within key groups, keys are preferably positioned based on more finger- 
comfortable key positions being allocated to keys with assumed (hypothesized) frequency of use, where 
such preference is reasonable and is treated more as art rather than a statistically determined outcome. 

In LeonovQWERTY version 1.0, all keys are grouped into the following key groups: QWERTY, 
Special, Modifier, Cursor, Digit, and Textual. While QWERTY and Digit key groups are self-explanatory, a 
few words to define the other key groups are in order: Specials are the special characters that are used 
when writing in programming languages, when composing and typing texts, and when working with 
spreadsheets or e.g. two-hand calculator software. Cursor keys are all the keys that involve cursor-related 
actions and cursor movements, while doubling as other navigation input. Textuals are the characters used 
when typing texts, especially basic sentence punctuation. 

The Modifier group deserves a dedicated paragraph: While ErgoDox supports many keyboard 
layers, LeonovQWERTY is designed to use as few layers as possible, primarily with the standard modifiers 
Shift, Control, Altmode, Caps, and Function. This is done for efficiency and in order to promote and 
facilitate the keyboard's use by an uninitiated broader audience. LeonovQWERTY mainly relies on two 
notable modifiers - Shift and Function (FN). Shift is used to get QWERTY capital characters, upper- 
inscription Specials, and upper-inscription Textuals, while Function (FN) is used to get Fl-12 and Print 
Screen (PR SC). The current layout only includes basic mathematical operator characters in order to 
balance the most common needs of all intended user groups. NB, it is possible to map APL-unique 
characters to the QWERTY (e.g. Alt) and Digits (Shift) with the use of one or two Modifiers, but I wouldn't 
want to clutter everybody's keyboard with a host of :) weird characters. 

LeonovQWERTY contains one "white key" that does not belong to any identified group: it is 
intended for Operating System (OP SYS) use, whatever most important use an operating system may find 
for it (e.g. Windows key), and for Print Screen (when using the Function modifier). 



Hardware: Full-Hand Case and Additional Soft Pad Requirements 

It is a requirement for acceptance of LeonovQWERTY on an ErgoDox Keyboard that the "full-hand" 
ErgoDox case is used, and that a very thick soft pad/cushion for the wrist be added in the square area 
where the wrist rests (adjacent to the main key set and to the thumb key cluster), such that does not 
obstruct the left-right movement of the thumb part of the palm in front of the thumb key cluster. 

Specifically, I recommend that the soft pad is 7-10 millimeters thick in total and consists of: an 
additional 5mm acrylic layer on top of the full-hand ErgoDox case, plus on top of that an additional layer 
of neoprene, plus a layer of synthetic leather to provide a more frictionless surface that offers a more 
comfortable touch experience to the resting wrist and that offers some customization options (e.g. 
metallic color, animal skin pattern, various textures, etc.). 

The additional acrylic layer, the neoprene layer, and the synthetic leather layer, should all be 
produced, that is cut, using one common contour (perhaps even one common file), and then assembled 
by being bolted together with flat-headed countersunk screws resting on countersunk or flush finishing 
washers and inserted through common holes that in turn penetrate the entire bulk/thickness of the case. 

If anybody with access to the full-hand ErgoDox case files expresses interest, please get in touch 
with me at max@leonovqwerty.org to work out together the contours and exact placement of this soft 
pad. For typing testing purposes on existing ErgoDox keyboards with the full-hand case, any soft material 
of the given or other tested height can be used. 

I believe this solution is promising, because: (A) It allows the four fingers to curl farther inward and 
thus span a longer distance, and as a result comfortably cover all five rows up and down. (B) It has the 
potential to eliminate having to build a separate-PCB key cluster on a differently inclined plane for the 
thumb keys, because it raises the wrist and lowers the thumb into its natural lower position and as a 
result makes the thumb travel downward (as opposed to upward and then downward) in order to hit a key 
from the thumb key cluster. 
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Hardware: Color-Coded Keycaps with a Style of Inscriptions (Key Legends) 

I strongly recommend making all keycaps uniquely color-coded by group, meaning a different 
keycap color per each functional key group, in order to utilize the user's peripheral vision in the typing 
process, which may be particularly helpful to novice users of this layout. (NB, another potential use for the 
color coding of keycaps on keyboards is to distinguish keys that belong to one key group and yet are 
placed (due to lack of keyboard's real estate) separately from their key group.) There can be several color 
schemes to suit a personal preference (yet limited in order to keep down the current manufacturing 
costs), as long as the key groups are easily distinguished by the user's peripheral vision. 

QWERTY keys preferably feature only capital-letter inscriptions that are centered in the lower half 
of the keycap - lower half in order to retain the exact inscription placement while allowing for possible 
production of specialized keyboards with modifier-enabled meanings mapped to the QWERTY keys. I 
personally prefer capitals for all keys, as the all-capital font looks "cool tech". 

Those keys in LeonovQWERTY that also have modifier-enabled meanings, preferably feature the 
inscription for the direct (main) input centered in the lower half of the keycap, while the modifier-enabled 
input inscription is placed in one of the upper two quarters of the keycap in a symmetric arrangement (to 
align with the symmetric ErgoDox hardware), so that for example Shift-enabled inscriptions are in the 
upper-right quarter of keycaps on the left-hand keyboard and in the upper-left quarter of keycaps on the 
right-hand keyboard, and the Function-enabled inscriptions are in exactly the opposite quarter placement 
- upper right quarter of keycaps on the right-hand keyboard. 

The reason why I settled for upper-half modifier-enabled inscriptions on keycaps is the better 
visibility that the upper half of the keycap seems to offer for the inscription above the finger tips - and 
when you are holding a modifier key, you'd better see clearly which key you need to hit next. And the 
inscriptions "FN", "F1-F12", and "PR SC", on keycaps are preferably one distinct text color that is different 
from all other keys' text color(s) on the keyboard, borrowing this design feature from programmable 
calculators. 



Hardware: Aspects of ErgoDox's Real Estate 

Since ErgoDox is an open-source product, LeonovQWERTY is using the ErgoDox hardware as-is in 
order to introduce more efficiency into they keyboard's development effort and to provide a pressure-free 
evolutionary approach rather than a perpetual staggered-redesign approach, which happens in situations 
where a new person/group comes in and without the prior guy's knowledge redesigns the thing just to 
prove that they are innovating (i.e. resources wasting and inefficient innovation practices). The same idea 
applies to the fact that this layout seeks to attempt to exploit ErgoDox's as-is potential to the fullest while 
retaining the single-PCB design and as simple assembly as possible that is suitable for an enthusiastic do- 
it-yourself user, while trying to increase the ergonomics without yet introducing further complexity into 
the PCB and into the case. (That is, in contrast to such more intrusive measures as splitting the PCB and 
to providing a separate PCB for the thumb key cluster at an angle to the plane of the main key set, which 
would also necessitate a case that is more complex/difficult/expensive to build.) 

A major open question then is whether the ErgoDox's real estate (i.e. layout of mechanical keys) 
can offer comfortable handling of QWERTY moved to the upper rows, and whether using the thumb key 
cluster is comfortable from that upper-row-QWERTY wrist position. Considering that, acceptance of 
LeonovQWERTY may require (hopefully not!) PCB redesign for partial repositioning of some keys, 
particularly in the thumb key cluster, and/or for adjustment of the current vertical staggering of key 
columns (or perhaps even dropping the column staggering altogether). 

The leftmost and rightmost key rows of the main key set of ErgoDox can either feature keycaps 
the same wider size as of the typical ErgoDox layout or be reduced/changed to the common size of all 
other keycaps in the main key set (which in turn would require layout changes in the PCB and case files), 
depending on which proves to offer a more comfortable user experience. 

Additionally, if a trackball is used together with the ErgoDox keyboard, I second several users' 
central placement of the trackball in between the L and R keyboard, at the very least because it enables 
both right and left hands to use the trackball, which may be also a benefit to left-handed users. 

As many will notice, there is a potential for adding an extra key on the third row (from top) on both 
L and R keyboard - by reducing the size of the two long keycaps in the innermost column. I could not find 
much use for such two additional hypothetical keys - it could be useful to have an extra Enter on the L 
keyboard and an extra Shift on the R keyboard, but to me personally at this point it does not yet seem 
worth anyone's time and effort to make all the changes in the hardware files. Time could tell otherwise, 
and then the keyboard layout could be adjusted, yet for now it seems as something we can live without. 
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A Note for Users of Dvorak, Colemak, and Etcetera 

I made this layout QWERTY, and even though I have no personal preference for QWERTY, Dvorak, 
Colemak, etc, in any case I do not want to torture a lot of people by forcing them to switch keyboard 
layouts, aside from the fact that widespread adoption of a new alphabetic layout seems pretty unrealistic 
at the present. Also, it would hurt ErgoDox's chances (if used jointly with say Dvorak) as a new product in 
expanding its user base. So I am sticking with QWERTY 

On the bright side, the English alphabetic character set is the same for QWERTY and Dvorak, 
Colemak, etc. So, if you are building an ErgoDox yourself and opt to use LeonovQWERTY, you can place 
the alphabetic characters where you want them to be. If you are buying a completed ErgoDox with 
LeonovQWERTY, then you can get a keycap puller (made of wire or plastic) to pluck out the alphabetic 
keys and then stick them in where you want them to be. 



Conclusions 

Here is what I learned as an inventor while designing this layout: 

1) There will never be a perfect mechanical keyboard layout, because different users use their 
keyboards to tackle different tasks and therefore have unique and therefore mutually 
contradicting layout ideals. 

2) There needs to be one common layout for mechanical keyboards, at least a common layout 
of alphabetic keys (QWERTY or Dvorak or Colemak), so that users can participate in the use of 
various computers. On the other hand, if anyone wants a blank-keycaps or entirely 
personalized layout, they have virtually limitless options to suit their taste and enjoy their 
keyboard experience to the fullest. 

3) Even if complex methodologies are developed for arriving at an optimum keyboard layout, 
the kind of thinking that goes into it definitely constitutes an 'art' rather than 'science' (with 
the notable exception of the human anatomy/physiology involved). 

Every time an input is mapped to a given mechanical key or is moved to another key, it 
automatically causes a host of layout interdependencies with other mechanical keys, and those layout 
interdependencies can be divided into three categories: 

a) Typing activity related interdependencies: what other keys are used frequently during the 
expected typing activity? Even the typing activity for a particular report or a spreadsheet or a 
software code is unrepeatably unique. 

b) Hand anatomy/physiology related interdependencies: which fingers can strike the given 
mechanical key, which other mechanical keys can those fingers strike, and which fingers will 
be striking other mechanical keys (both adjacent and farthest keys)? This becomes much 
more complicated when we consider different palm sizes and different finger lengths per each 
given palm size. 

c) Keyboard real estate related interdependencies: how many keys the keyboard consists of on 
any given row and in any given column, and how many rows and column are there? That real 
estate will determine and limit the layout possibilities/options for assigning all other inputs 
once one input is assigned to one mechanical key. 

Note that the above three categories are interdependent, so a layout interdependency in one 
category will influence an interdependency in another category, and so on. 



Legal Disclaimer 

LeonovQWERTY layout is only intended to improve the typing comfort in the context of user experience. 
This layout is not a medical/healthcare solution and is explicitly not intended to address any medical 
condition. The use of this layout may pose unexpected health risks, for which every single user agrees to 
take personal sole responsibility by starting to use this layout. Consult a doctor if you detect unusual 
symptoms in your hands. The author of LeonovQWERTY does not accept any liability and does not offer 
any warranty. This is an untested experimental layout, so use strictly at your own risk! 

P.5. I used my lastname for this keyboard layout in order to ensure the right of use of the product name 
without having to trademark it and thus cut on unnecessary costs. 
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